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DETAILED ACTION 

1 . Claims 1-30 have been presented for examination. 

Claim Rejections - 35 USC § 102 

2. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the 
basis for the rejections under this section made in this Office action: 

A person shall be entitled to a patent unless - 

(e) the invention was described in (1) an application for patent, published under section 122(b), by another filed 
in the United States before the invention by the applicant for patent or (2) a patent granted on an application for 
patent by another filed in the United States before the invention by the applicant for patent, except that an 
international application filed under the treaty defined in section 351(a) shall have the effects for purposes of this 
subsection of an application filed in the United States only if the international application designated the United 
States and was published under Article 21(2) of such treaty in the English language. 

3. Claims 1-4, 6, 7, 14 and 15 are rejected under 35 U.S.C. 102(e) as being anticipated by 
Isfeld et al. (US 5,828,835, hereinafter Isfeld). 

4. As per claim 1, Isfeld teaches a method of outputting a first TCP/IP packet and a second 
TCP/IP packet from a network interface device, the first TCP/IP packet and the second TCP/IP 
packet being output to a network (e.g. Isfeld, Abstract; col. 1, lines 20-27), comprising: 

(a) storing first packet information on the network interface device (e.g. Isfeld, col. 2, 
lines 59-63; col. 3, lines 16-29); 

(b) pushing a first pointer to the first packet information onto a first transmit queue of the 
network interface device (e.g. Isfeld, col. 2, lines 59-63; col. 3, lines 16-29); 

(c) storing second packet information on the network interface device (e.g. Isfeld, col. 2, 
lines 59-63; col. 3, lines 16-29); 
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(d) pushing a second pointer to the second packet information onto a second transmit 
queue of the network interface device (e.g. Isfeld, col. 2, lines 59-63; col. 3, lines 16-29); and 

(e) popping the second pointer off the second transmit queue and then popping the first 
pointer off the first transmit queue, the popped second pointer being used to locate the second 
packet information, the located second packet information then being output from the network 
interface device in the form of a second TCP/IP packet, the popped first pointer being used to 
locate the first packet information, the located first packet information being output from the 
network interface device in the form of a first TCP/IP packet such that the second TCP/IP packet 
is output from the network interface device and to the network before the first TCP/IP packet is 
output from the network interface device and to the network (e.g. Isfeld, col. 2, lines 54-67; col. 
3, lines 1-15). 

5. As per claim 2, Isfeld teaches the method of claim 1, wherein the first TCP/IP packet is a 
data packet, wherein the second TCP/IP packet is a control packet (e.g. Isfeld, col. 1, lines 60-67; 
col. 2, lines 1-3), and wherein the network interface device is coupled to a host computer by a 
parallel bus (e.g. Isfeld, col. 6, lines 13-17). 

6. As per claim 3, Isfeld teaches the method of claim 1, wherein the first transmit queue 
contains pointers associated with a first set of packets, and wherein the second transmit queue 
contains pointers associated with a second set of packets, the second set of packets having 
transmission priority over the first set of packets (e.g. Isfeld, col. 2, lines 54-67; col. 3, lines 1- 
15). 
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7. As per claim 4, Isfeld teaches the method of claim 1 , wherein the network interface 
device comprises a transmit sequencer, a memory, and MAC interface circuitry, the transmit 
sequencer causing the second packet information to be transferred from the memory to the MAC 
interface circuitry, the second TCP/IP packet being output from the network interface device 
through the MAC interface circuitry (e.g. Isfeld, col. 6, lines 36-44; col. 7, lines 24-27). 

8. As per claim 6, Isfeld teaches the method of claim 1 , wherein the first packet information 
includes a header portion and a data payload portion (e.g. Isfeld, col. 8, lines 50-54; col. 10, lines 
44-47). 

9. As per claim 7, Isfeld teaches the method of claim 1 , wherein the first pointer is part of a 
buffer descriptor (e.g. Isfeld, col. 21, lines 21-29). 

10. As per claim 14, Isfeld teaches a TCP/IP offload network interface device (e.g. Isfeld, 
Abstract; col. 1, lines 20-27), comprising: 

a memory containing first packet information and second packet information (e.g. Isfeld, 
col. 2, lines 59-63; col. 3, lines 16-29); 

a processor that causes a first pointer to the first packet information to be pushed onto a 
first transmit queue before a second pointer to the second packet information is pushed onto a 
second transmit queue (e.g. Isfeld, col. 2, lines 54-67; col. 3, lines 1-15); and 
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a transmit mechanism that pops the second queue in preference to popping the first 
queue, the first transmit mechanism popping the second pointer off the second queue and 
outputting the second packet information from the network interface device in the form of a 
second TCP/IP packet, the transmit mechanism popping the first pointer off the first queue and 
outputting the first packet information from the network interface device in the form of a first 
TCP/IP packet, the transmit mechanism popping the second pointer from the second queue 
before popping the first pointer off the first queue, the second TCP/IP packet being output from 
the network interface device before the first TCP/IP packet is output from the network interface 
device (e.g. Isfeld, col. 2, lines 54-67; col. 3, lines 1-15). 

11. As per claim 1 5, Isfeld teaches the TCP/IP offload network interface device of claim 1 4, 
wherein the first TCP/IP packet is a data packet, and wherein the second TCP/IP packet is a 
control packet (e.g. Isfeld, col. 1, lines 60-67; col. 2, lines 1-3). 

Claim Rejections - 35 USC § 103 

12. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

13. The factual inquiries set forth in Graham v. John Deere Co,, 383 U.S. 1, 148 USPQ 459 
(1966), that are applied for establishing a background for determining obviousness under 35 
U.S.C. 103(a) are summarized as follows: 
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1 . Determining the scope and contents of the prior art. 

2. Ascertaining the differences between the prior art and the claims at issue. 

3. Resolving the level of ordinary skill in the pertinent art. 

4. Considering objective evidence present in the application indicating obviousness 
or nonobviousness. 

14. Claims 5, 9, 1 1 and 16-18 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Isfeld et al. (US 5,828,835, hereinafter Isfeld) in view of Lakshman et al. (US 6,078,564, 
hereinafter Lakshman). 

15. As per claim 5, Isfeld teaches the method of claim 1 , wherein the pushing of (b) occurs 
before the pushing of (d) (e.g. Isfeld, col. 2, lines 54-67; col. 3, lines 1-15). 

Isfeld fails to teach the method wherein the first TCP/IP packet is associated with a first 
TCP/IP connection, and wherein the second TCP/IP packet is associated with a second TCP/IP 
connection. 

However, in a similar art, Lakshman teaches a network communications system that uses 
multiple transmit queues, one for control (ACK) packet pointers and one for data packet pointers, 
using a separate connection per transmit queue (e.g. Lakshman, col. 3, lines 26-33). 

It would have been obvious to one skilled in the art at the time the invention was made to 
combine Lakshman with Isfeld because of the advantages of allowing separate packets to be 
associated with separate network connections. It is well known in the art that network 
communication systems very often include a large number of network connections. Allowing 
packets to be transmitted and received over various connections at various times is a standard 
feature for any communication network. The use of multiple network connections helps to 
eliminate network congestion that would occur when using only a single connection. Network 
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congestion can greatly slow down the speed and efficiency of packet transmission, often times 
leading to dropped or lost packets. Reducing or eliminating network congestion is advantageous 
in any computer network system. 

16. As per claim 9, Isfeld teaches the method of claim 1, wherein the second TCP/IP packet 
is a control packet (e.g. Isfeld, col. 1, lines 60-67; col. 2, lines 1-3), but fails to teach the method 
wherein the second TCP/IP packet is a TCP ACK. 

However, in a similar art, Lakshman teaches a network communications system that uses 
multiple transmit queues, one for control (ACK) packet pointers and one for data packet pointers, 
and the various uses of the ACK control packet (e.g. Lakshman, col. 4, lines 38-44, 53-59). 

It would have been obvious to one skilled in the art at the time the invention was made to 
further combine Lakshman with Isfeld because of the benefits of using an acknowledgement 
(ACK) response in a communications network. The use of ACK responses further assists a 
communications network in reducing network congestion and informs the transmitter when a 
packet has been dropped. This increases the speed, efficiency and reliability of a network, all of 
which are beneficial to any communications network. 

17. As per claim 11, Isfeld teaches the method of claim 1 wherein the first transmit queue is 
used for the transmission of TCP/IP data packets(e.g. Isfeld, col. 1, lines 60-67; col. 2, lines 1-3). 

Isfeld fails to teach the method wherein the second transmit queue is used for the 
transmission of TCP ACKs, the second transmit queue being free of or substantially free of 
pointers to TCP/IP data packets. 
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However, in a similar art, Lakshman teaches a network communications system that uses 
multiple transmit queues, one for control (ACK) packet pointers and one for data packet pointers, 
each pointer type being placed into its own queue, leaving the other queues free of unnecessary 
types of information (e.g. Lakshman, col. 4, lines 53-59; Fig. 4) 

It would have been obvious to one skilled in the art at the time the invention was made to 
combine Lakshman with Isfeld for similar reasons as stated above in regards to claim 9. 

18. As per claim 16, Isfeld teaches the TCP/IP offload network interface device of claim 14, 
but fails to teach the method wherein the first TCP/IP packet is a data packet associated with a 
first TCP/IP connection and wherein the second TCP/IP packet is a TCP ACK associated with a 
second TCP/IP connection. 

However, in a similar art Lakshman teaches a network communications system that uses 
multiple transmit queues, one for ACK packet pointers and one for data packet pointers, using a 
separate connection per transmit queue (e.g. Lakshman, col. 3, lines 26-33). 

It would have been obvious to one skilled in the art at the time the invention was made to 
combine Lakshman with Isfeld for similar reasons as stated above in regards to claim 5. 

1 9. As per claim 1 7, Isfeld and Lakshman teach the TCP/IP offload network interface device 
of claim 16, wherein the TCP/IP offload network interface device is operatively coupled to a host 
computer, the host computer executing a protocol processing stack (e.g. Isfeld, col. 8, lines 16- 
34). 
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20. As per claim 18, Isfeld and Lakshman teach the TCP/IP offload network interface device 
of claim 16, wherein the network interface device includes a second processor, the second 
processor executing a protocol processing stack, the second processor being part of the TCP/IP 
offload network interface device (e.g. Isfeld, col. 8, lines 16-34). 

21. Claims 8, 12 and 13 are rejected under 35 U.S.C. 103(a) as being unpatentable over Isfeld 
et al. (US 5,828,835, hereinafter Isfeld) in view of Kapoor et al. (US 5,682,534, hereinafter 
Kapoor). 

22. As per claim 8, Isfeld teaches the method of claim 1, but fails to teach the method further 
comprising: 

receiving onto the network interface device from the network a third packet; 

fast-path processing the third packet on the network interface device such that a data 
payload portion of the third packet is written into a destination memory without a network 
protocol stack performing substantial transport or substantial network layer protocol processing 
on the third packet; 

receiving onto the network interface device from the network a fourth packet; and 
slow-path processing the fourth packet such that at least a data payload portion of the 
fourth packet is written into the destination memory, the network protocol stack performing 
substantial transport and substantial network layer protocol processing on the fourth packet. 

However, in a similar art, Kapoor teaches a network communication system that receives 
packets onto a network interface device and is able to perform both "fast-path" and "slow-path" 
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processing on the packet, depending on certain characteristics determined at the time the packet 
is received; the "fast-path" processing avoids protocol processing in both the network and 
transport layers, accelerating the packet through the device (e.g. Kapoor, col. 2, lines 33-49; col. 
6, lines 7-19; Fig. 2B) and the "slow-path" processing processes the packet through all applicable 
layers of the protocol stack if it does not meet the defined requirements for "fast-path" 
processing (e.g. Kapoor, col. 5, lines 36-45). 

It would have been obvious to one skilled in the art at the time the invention was made to 
combine Kapoor with Isfeld because of the advantages of allowing certain packets which do not 
need full protocol stack processing to avoid the unnecessary processing and be given a "fast- 
path" through the device. As Kapoor states, bypassing the unnecessary processing layers 
provides for significant performance gains (e.g. Kapoor, col. 2, lines 48-49). When the network 
device skips processing on each layer of the protocol stack, the packet passes through the device 
much faster and more efficiently. Only packets that need to be processed in each layer are pass 
through the "slow-path" which can greatly increase the speed and efficiency of network 
communication. This is beneficial in any computer network. 

23. As per claim 12, Isfeld and Kapoor teach the method of claim 8, wherein the network 
protocol stack is executed by a processor, the processor being a part of the network interface 
device (e.g. Kapoor, col. 2, lines 33-43). 
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24. As per claim 13, Isfeld ?nd Kapoor teach the method of claim 8, wherein the network 
protocol stack is executed by a processor, the processor being part of a host computer, the 
network interface device being coupled to the host computer (e.g. Kapoor, col. 2, lines 33-43). 

25. Claim 10 is rejected under 35 U.S.C. 103(a) as being unpatentable over Isfeld et al. (US 
5,828,835, hereinafter Isfeld) in view of Kapoor et al. (US 5,682,534, hereinafter Kapoor) as 
applied to claim 8 above, and further in view of Lakshman et al. (US 6,078,564, hereinafter 
Lakshman). 

26. As per claim 10, Isfeld and Kapoor teach the method of claim 8, but fail to teach wherein 
the second TCP/IP packet is a TCP ACK. 

However, in a similar art, Lakshman teaches a network communications system that uses 
multiple transmit queues, one for control (ACK) packet pointers and one for data packet pointers, 
and the various uses of the ACK control packet (e.g. Lakshman, col. 4, lines 38-44, 53-59). 

It would have been obvious to one skilled in the art at the time the invention was made to 
further combine Lakshman with Isfeld because of the benefits of using an acknowledgement 
(ACK) response in a communications network. The use of ACK responses further assists a 
communications network in reducing network congestion and informs the transmitter when a 
packet has been dropped. This increases the speed, efficiency and reliability of a network, all of 
which are beneficial to any communications network. 
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27. Claims 21-25 are rejected under 35 U.S.C. 103(a) as being unpatentable over Isfeld et al. 
(US 5,828,835, hereinafter Isfeld) in view of Kapoor et al. (US 5,682,534, hereinafter Kapoor) 
and further in view of Lakshman et al. (US 6,078,564, hereinafter Lakshman). 

28. As per claim 21, Isfeld teaches a method for outputting a control packet from a protocol 
processing offload network interface device (PPONID), the PPONID being coupled to a network 
(e.g. Isfeld, Abstract; col. 1, lines 20-27), the method comprising: 

receiving a first packet onto the PPONID from the network (e.g. Isfeld, col. 2, lines 59- 
63; col. 3, lines 16-29); 

receiving a second packet onto the PPONID from the network (e.g. Isfeld, col. 2, lines 
59-63; col. 3, lines 16-29); 

pushing a first pointer to the first packet information onto a first transmit queue (e.g. 
Isfeld, col. 2, lines 59-63; col. 3, lines 16-29); 

in response to said receiving of the second packet pushing a second pointer to the second 
packet information onto a second transmit queue (e.g. Isfeld, col. 2, lines 59-63; col. 3, lines 16- 
29); 

popping the second transmit queue to retrieve the second pointer, and using the second 
pointer to retrieve the second packet information, and outputting the second packet information 
from the PPONID in the form of the control packet (e.g. Isfeld, col. 2, lines 54-67; col. 3, lines 1- 
15); and 

popping the first transmit queue to retrieve the first pointer, and using the first pointer to 
retrieve the first packet information, and outputting the first packet information from the 



Application/Control Number: 10/085,802 Page 13 

Art Unit: 2154 

PPONID in the form of a third packet, the control packet being output from the PPONID before 
the third packet (e.g. Isfeld, col. 2, lines 54-67; col. 3, lines 1-15). 

Isfeld fails to teach the method wherein the control packet is an acknowledge (ACK) and 
the method comprising: slow-path processing the first packet such that a protocol processing 
stack performs substantial transport layer processing and substantial network layer processing on 
the first packet; fast-path processing the second packet on the PPONID such that the stack 
performs substantially no transport layer processing on the second packet and such that the stack 
performs substantially no network layer processing on the second packet. 

However, in a similar art, Kapoor teaches a network communication system that receives 
packets onto a network interface device and is able to perform both "fast-path" and "slow-path" 
processing on the packet, depending on certain characteristics determined at the time the packet 
is received; the "fast-path" processing avoids protocol processing in both the network and 
transport layers, accelerating the packet through the device (e.g. Kapoor, col. 2, lines 33-49; col. 
6, lines 7-19; Fig. 2B) and the "slow-path" processing processes the packet through all applicable 
layers of the protocol stack if it does not meet the defined requirements for "fast-path" 
processing (e.g. Kapoor, col. 5, lines 36-45). 

Also, in a similar art, Lakshman teaches a network communications system that uses 
multiple transmit queues, one for control (ACK) packet pointers and one for data packet pointers, 
and the various uses of the ACK control packet (e.g. Lakshman, col. 4, lines 38-44, 53-59). 

It would have been obvious to one skilled in the art at the time the invention was made to 
combine Kapoor and Lakshman with Isfeld because of the benefits of using ACK responses and 
allowing packets to be processed only in the protocol layers which are necessary for 
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transmission. The use of ACK responses further assists a communications network in reducing 
network congestion and informs the transmitter when a packet has been dropped. As Kapoor 
states, bypassing the unnecessary processing layers provides for significant performance gains 
(e.g. Kapoor, col. 2, lines 48-49). When the network device skips processing on each layer of 
the protocol stack, the packet passes through the device much faster and more efficiently. Only 
packets that need to be processed in each layer are pass through the "slow-path" which can 
greatly increase the speed and efficiency of network communication. All of these features are 
beneficial in any computer communications network. 

29. As per claim 22, Isfeld, Kapoor and Lakshman teach the method of claim 21, wherein 
PPONID is coupled to a host computer (e.g. Isfeld, col. 6, lines 13-17), and wherein the second 
packet includes a data payload (e.g. Isfeld, col. 8, lines 50-544; col. 10, lines 44-47), the data 
payload being transferred from the PPONID and to the host, the ACK (e.g. Lakshman, col. 4, 
lines 38-44, 53-59) being output from the PPONID before any portion of the data payload is 
transferred to the host (e.g. Isfeld, col. 2, lines 54-67; col. 3, lines 1-15). 

30. As per claim 23, Isfeld teaches a method for outputting a control packet from a network 
interface device, the network interface device being coupled to a network (e.g. Isfeld, Abstract; 
col. 1, lines 20-27), the method comprising: 

receiving a first TCP/IP packet onto the network interface device from the network (e.g. 
Isfeld, col. 2, lines 59-63; col. 3, lines 16-29); 
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receiving a second TCP/IP packet onto the network interface device from the network 
(e.g. Isfeld, col. 2, lines 59-63; col. 3, lines 16-29); 

pushing a first pointer to a third packet information onto a first transmit queue (e.g. 
Isfeld, col. 2, lines 59-63; col. 3, lines 16-29); 

in response to said receiving of the second TCP/IP packet pushing a second pointer to 
fourth packet information onto a second transmit queue (e.g. Isfeld, col. 2, lines 59-63; col. 3, 
lines 16-29); 

popping the second transmit queue to retrieve the second pointer, and using the second 
pointer to retrieve the fourth packet information, and outputting the fourth packet information 
from the network interface device in the form of the control packet (e.g. Isfeld, col. 2, lines 54- 
67; col. 3, lines 1-15); and 

popping the first transmit queue to retrieve the first pointer, and using the first pointer to 
retrieve the third packet information, and outputting the third packet information from the 
network interface device in the form of a third TCP/IP packet, the control packet being output 
from the network interface device before the third TCP/IP packet (e.g. Isfeld, col. 2, lines 54-67; 
col. 3, lines 1-15). 

Isfeld fails to teach the control packet being a TCP ACK from a network device and the 
method comprising: slow-path processing the first TCP/IP packet such that a protocol 
processing stack performs substantial TCP layer processing and substantial IP layer processing 
on the first TCP/IP packet; fast-path processing the second TCP/IP packet on the network 
interface device such that the stack performs substantially no TCP layer processing on the second 
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TCP/IP packet and such that the stack performs substantially no IP layer processing on the 
second TCP/IP packet. 

However, in a similar art, Kapoor teaches a network communication system that receives 
packets onto a network interface device and is able to perform both "fast-path" and "slow-path" 
processing on the packet, depending on certain characteristics determined at the time the packet 
is received; the "fast-path" processing avoids protocol processing in both the network and 
transport layers, accelerating the packet through the device (e.g. Kapoor, col. 2, lines 33-49; col. 
6, lines 7-19; Fig. 2B) and the "slow-path" processing processes the packet through all applicable 
layers of the protocol stack if it does not meet the defined requirements for "fast-path" 
processing (e.g. Kapoor, col. 5, lines 36-45). 

Also, in a similar art, Lakshman teaches a network communications system that uses 
multiple transmit queues, one for control (ACK) packet pointers and one for data packet pointers, 
and the various uses of the ACK control packet (e.g. Lakshman, col. 4, lines 38-44, 53-59). 

It would have been obvious to one skilled in the art at the time the invention was made to 
combine Kapoor and Lakshman with Isfeld for similar reasons as stated above in regards to 
claim 21. 

31. As per claim 24, Isfeld, Kapoor and Lakshman teach the method of claim 23, wherein the 
protocol processing stack executes on a host computer, the network interface device being 
coupled to the host computer (e.g. Isfeld, col. 8, lines 19-34). 
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32. As per claim 25, Isfeld, Kapoor and Lakshman teach the method of claim 23, wherein the 
protocol processing stack executes on a processor, the processor being part of the network 
interface device (e.g. Isfeld, col. 8, lines 19-34). 

33. Claims 29 and 30 are rejected under 35 U.S.C. 103(a) as being unpatentable over Kapoor 
et al. (US 5,682,534, hereinafter Kapoor) in view of Isfeld et al. (US 5,828,835, hereinafter 
Isfeld). 

34. As per claim 29, Kapoor teaches a TCP/IP offload device, the TCP/IP offload device 
being coupled to a device that executes a protocol stack, wherein the TCP/IP offload device 
accelerates TCP and IP protocol processing of an incoming TCP/IP packet such that the stack 
performs substantially no TCP protocol processing on the TCP/IP packet and such that the stack 
performs substantially no IP protocol processing on the TCP/IP packet, and wherein a data 
portion of the TCP/IP packet is transferred from the TCP/IP offload device to the device that 
executes the protocol stack (e.g. Kapoor, col. 2, lines 33-49; col. 6, lines 7-19; Fig. 2B). 

Kapoor fails to teach the TCP/IP offload device comprising: a first transmit queue 
containing pointers associated with a first set of packets; and a second transmit queue containing 
pointers associated with a second set of packets, wherein the second set of packets has 
transmission priority over the first set of packets. 

However, in a similar art, Isfeld teaches a system that uses two separate transmit queues 
to store pointers to memory locations containing data packet information and control packet 
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information, and where the second transmit queue has transmission priority over the first 
transmit queue (e.g. Isfeld, col. 2, lines 54-67; col. 3, lines 1-15). 

It would have been obvious to one skilled in the art at the time the invention was made to 
combine Isfeld with Kapoor because of the advantages of using separate transmit queues for 
storing pointers to different types of information. This allows the data information and control 
information to remain separated and provides for a variation in processing to be done to one 
queue and not the other. Keeping data and control information separate reduces the time spent 
for the processor to determine which type of information it is dealing with every time it needs to 
process a packet. This allows the processor to quickly and efficiently conduct the necessary 
processing and transmit the packet appropriately. The increase in speed and efficiency is a 
benefit in any computer network. 

35. As per claim 30, Kapoor and Isfeld teach the TCP/IP offload device of claim 29, wherein 
the TCP/IP packet is received onto the TCP/IP offload device from a network, and wherein the 
TCP/IP offload device includes means for outputting the first set of packets and the second set of 
packets from the TCP/IP offload device and to the network (e.g. Kapoor, col. 2, lines 33-49; col. 
6, lines 7-19). 

Allowable Subject Matter 

36. Claims 19, 20, 26 and 27 are objected to as being dependent upon a rejected base claim, 
but would be allowable if rewritten in independent form including all of the limitations of the 
base claim and any intervening claims. 
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As per claims 19 and 26, Prior Art does not teach the additional limitations of the use of a 
template header stored on a network interface device, the template header including TCP and IP 
fields, executing a finite state machine within the network interface device to fill in the TCP and 
IP fields to form a part of packet information. 

As per claim 20, Prior Art does not teach the device of claim 19, including the limitation 
that the transmit finite state machine specifically does not include discrete TCP layer protocol 
processing and a discrete IP layer protocol processing, that the transmit finite state machine 
covers both TCP and IP protocol processing. 

As per claim 27, Prior Art does not teach the method of claim 26, including the limitation 
that a transmit sequencer causes the TCP ACK and third TCP/IP packet to be output. 

37. Claim 28 is allowed. 

Conclusion 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Eric Kuiper whose telephone number is (571) 272-0953. The 
examiner can normally be reached on Monday through Friday, 8:00am to 4:30pm. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, John Follansbee can be reached on (571) 272-3964. The fax phone number for the 
organization where this application or proceeding is assigned is 571-273-8300. 
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Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). 

Eric Kuiper 

17 February 2006 




